| From: | Volker Barthelmann |
| Date: | 16 Apr 00 at 14:36:51 |
| Subject: | Re: VBCC-Problems |
On Sat, 15 Apr 2000, Stefan Schulze wrote:
> Why does VBCC complain about doubled defined smybols in the same object-file?
> (startup.o, copied from the StormC-package (V3.0) because there was no
> startup-code inside the vbcc-archive)
You cannot use startup-codes from other compilers. vbcc comes with its own
startup-codes and vc will use them by default (i.e. you must not specify
them as extra object files). You seem to have an installation-problem or a
broken archive. What archives do you have and where did you get them from?
> Why doesn't VBCC know the function specifier __inline?
It's a compiler-specific extension. vbcc will usually decide by itself
what functions should be inlined. There is #pragma only-inline on/off in
vbcc.
> What means the command line parameter -l? I read something about a "library
> specifier" in the docs. Should that -l mean which linker-libs are taken?
Yes.
> If
> yes, where can I get these linker-libs? (for 68020+ and for WarpOS) And why
> aren't they inside the archive when they're needed to compile anything?
Again, all the libraries you need should be in the appropriate archives.
If you have the archive vbccm68k.lha then there should be a subdirectory
vbcc/machines/amiga68k/lib containing, among others, startup.o and vc.lib.
When you cd into vbcc/machines/amiga and execute init_vbcc the necessary
assigns should be set so that vbcc will find its headers and libraries.
> I got many warnings during compile about missing semicolons and some other
> things directly after some #include-instructions. But the number changed from
> time to time depending on the order VBCC compiles my sources. Which
> differences must be taken into account from Storm to VBCC? (because I've also
> copied all missing include-files from StormC)
First, you can usually not use includes from another compiler unless they
are not compiler-specific (i.e. the original OS includes or most headers
for shared libraries can be used, whereas something like stdio.h can not).
Second, you have to check where your sources use extensions to standard C.
These are usually not understood by different compilers. While some
extensions are offered by most compilers (e.g. register arguments or
inline assembly), they rarely use the same syntax. So, you have to look
where you're using extensions to standard C and then check whether vbcc
offers them and, if so, how to write them in vbcc.
> Sometimes the linker says something like "global Symbol _Blabla (file.o)
> already defined in the_very_same_file.o". Why? And why does the number of
> doubled defined symbols change from time to time? Does this also depends on
> the order the files are compiled?
Sorry, I don't have enough information to comment on this. Probably an
installation-problem.
> If I compile with -O (Optimizing) on one particular file vbccm68k_wos eats all
> ram (55MB Fast and 2MB Chip) within half a minute and then exits with "not
> enough memory!". But the file is only around 30K big and some files are
> bigger then this. If I compile with -O3 (better optimizing) VBCC also eats
> all memory and freezes the systme then. Has somebody made similar
> experiences?
The optimizer does use a lot of RAM. The amount can vary widely depending
on the complexity of the source. The source code length is not so
important. Factors which increase RAM usage of the optimizer are:
- long functions
- many edges in the control-flow-graph (i.e. many branches/loops/ifs)
- many global variables
- a lot of pointer usage
If you compile the file with -E and send me the resulting .i file I will
have a look whether there is a problem and if RAM usage can be reduced.
The problem of freezing the system is typical for low memory situations
and probably not directly caused by vbcc. vbcc will allocate many
relatively small chunks of memory and do lots of calculations. Therefore,
there may be extremely little memory available for some time. In a
multitasking OS usually other things will happen during that time and, in
my experience, something will crash. AmigaOS (as well as many other
systems) is not stable in low memory situations, IMHO.
Hope this helps,
Volker
------------------------------------------------------------------------
IT Professionals: Match your unique skills with the best IT projects at
http://click.egroups.com/1/3381/1/_/451227/_/955922991/
------------------------------------------------------------------------